Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SecurityBundle] Set translator in AccessTokenAuthenticator in Security bundle config #54734

Open
wants to merge 10 commits into
base: 6.4
Choose a base branch
from

Conversation

dwgebler
Copy link

Q A
Branch? 6.4
Bug fix? yes
New feature? no
Deprecations? no
Issues
License MIT

The AccessTokenAuthenticator doesn't get configured with the translator service. This appears to be a bug, as this class's setTranslator is unused and the translator can't be injected anywhere else.

@smnandre
Copy link
Contributor

It has been removed as a fix: #50819

@dwgebler
Copy link
Author

It has been removed as a fix: #50819

I have amended this branch to an alternative solution; we try to translate, but revert the translation if the result contains any non-ASCII characters. I don't think the linked fix is the right one, really - it's just making it impossible to do any translation here at all, even if the result would be valid and RFC compliant.

@wouterj
Copy link
Member

wouterj commented Jun 9, 2024

What is the use-case for translating this message if - according to the RFC 6750 - it must not be displayed to the end user?

Also, this means we'll have deprecated translation strings in the repository (like Spanish as mentioned in #50811). I'm not sure how we are supposed to fix this, given you probably have to use non-ANCII characters in those languages.
This message is also used by other authenticators where the message is meant to be shown to users (like login form), so compromising the translations to fit only one specific authenticator also doesn't seem like a great option to me.

I'm still leaning towards not using the translator here for these arguments.

@dwgebler
Copy link
Author

What is the use-case for translating this message if - according to the RFC 6750 - it must not be displayed to the end user?

"Not displayed to users" isn't quite the same thing as "never seen by a human"; easy to imagine the reasons for authentication failures supplied in headers may end up in logs and as such the information may aid with various inquiry and analysis. It's also not necessarily the case that every system respects the RFC, as not every access token system is OAuth2 compliant, so we don't know this message won't be displayed.

Also, this means we'll have deprecated translation strings in the repository (like Spanish as mentioned in #50811). I'm not sure how we are supposed to fix this, given you probably have to use non-ANCII characters in those languages. This message is also used by other authenticators where the message is meant to be shown to users (like login form), so compromising the translations to fit only one specific authenticator also doesn't seem like a great option to me.

I would argue that allowing some translation, even if limited to ASCII characters, is useful. The case for translation may not necessarily be to another language, but e.g. alternative or simplified English for example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants